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34. (Amended) A method for providing a formatted output of selected fields of a 
database, wherein the database includes a number of database entries each having two or more fields, 
and each field having a field value, the method comprising: 

identifying the database entries that have one or more fields with a field value that matches a 
selected query or expression; and 

outputting a formatted output that includes the field value of a selected field of each database 
entry identified by the identifying step, wherein the formatted output is formatted to print onto 
printed labels, and wherein each of the printed labels is one of an array of printed labels on a sheet of 
printed labels. 

35. (Amended) A method for providing a formatted output of selected fields of a 
database, wherein the database includes a number of database entries each having two or more fields, 
and each field having a field value, the method comprising: 

identifying the database entries that have one or more fields with a field value that matches a 
selected value or expression; and 

outputting a formatted output that includes the field value of a selected field of each database 
entry identified by the identifying step, wherein the formatted output is formatted to be read into a 
personal digital assistant. 

48. (Newly Presented) A method according to claim 34 wherein the database resides 
on a server and the selected query or expression is identified via a WWW browser. 

49. (Newly Presented) A method according to claim 48 wherein the formatted output 
is compatible with a word processing program. 

Remarks 

The preceding amendments and following remarks are submitted in response to the Official 
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Action of the Examiner mailed November 20, 2002, setting a three-month shortened statutory period 
for response ending February 20, 2002. Claims 1 -49 remain pending in the application, with claims 
48-49 being newly presented. Reconsideration, examination and allowance of all pending claims are 
respectfully requested. 

In paragraph 2 of the Office Action, the Examiner rejected claims 24-33 under 35 U.S.C. § 
112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the 
subject matter which applicant regards as the invention. The Examiner states that the phrase 
"another program" in claim 24 is ambiguous because it is uncertain to which program or sort of 
program the applicant is referring to. For the sake of examination, the Examiner states that "another 
program" means "a formatting computer program". 

Claim 24 has been amended to recite a method for providing a formatted output of selected 
fields of a database for a computer program with a merge capability . Claim 24 has further been 
amended to recite: identifying the database entries that have one or more fields with a field value that 
matches a selected query or expression; and outputting a formatted output that includes the field 
value of a selected field of each database entry identified by the identifying step, wherein the 
formatted output is formatted as a merge document that can be read by the computer program with 
the merge capability [another program with a merge capability] . In view of the foregoing, claim 24 
is believed to fully comply with 35 U.S.C. § 112, second paragraph. Further, it is clear that the 
computer program does not have to be "a formatting computer program" as noted by the Examiner, 
but rather only needs to be "a computer program that has a merge capability". 

In paragraphs 3 and 4 of the Office Action, the Examiner rejected claims 25 and 26, 
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respectively, because the phrase "the program" lacks proper antecedent basis. Claims 25 and 26 
have been amended to provide proper antecedent basis. 

In paragraph 6 of the Office Action, the Examiner rejected claims 1, 2, 4, 6-16, 19, 20, 22 and 
36 under 35 U.S.C. § 102(e) as being anticipated by Kenna et al. (US 6,108,641). With respect to 
claims 1 and 16, the Examiner states that Kenna et al. suggests a system and method for displaying 
account information (citing Kenna et al., Figure 7, display 710) from two or more accounts that are 
stored in one or more account database. The Examiner further states that Kenna et al. also suggest a 
first data structure (citing Kenna et al., network server 650) having one or more associated links, 
wherein each account includes one or more account items (citing Kenna et al., column 9, lines 46- 
63). Finally, the Examiner states that Kenna et al. suggest display means 710 for displaying selected 
account items from the accounts identified by the one or more links of the first data structure (citing 
Kenna et al., computer 600, column 9, line 33 to column 10, line 44). 

After carefully reviewing Kenna et al., Applicants must respectfully disagree. Claim 1, as 
amended, recites: 

1 . (Amended) A system for displaying account information from two 
or more accounts that are stored in one or more account database, wherein each 
account includes one or more account items, the system comprising: 

a first data structure having [one] two or more associated links, wherein each 
link identifies one or more of the accounts; and 

display means for displaying selected account items from the accounts 
identified by the [one] two or more links of the first data structure. 

(Emphasis Added). As can be seen, claim 1 recites a first data structure that includes two or more 

associated links, wherein each link identifies one or more of the accounts . Claim 1 further recites 

display means for displaying selected account items from the accounts identified by the two or more 
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links of the first data structure . As noted in the present specification, this may provide certain 

advantages. For example, and with reference to Figure 4, the present specification states: 

When a representative is analyzing or discussing a customer's portfolio, it is 
highly desirable for the representative to have ready access to information regarding 
all of the customer's accounts. It is also highly desirable to be able to combine 
certain accounts "on the fly", such as several business accounts or all family accounts 
including 401K accounts. This may allow the representative to provide an overall or 
macro view of the customer's portfolio. To accomplish this, and in accordance with 
one illustrative embodiment of the present invention, the representative is allowed to 
create a data structure that has one or more associated links. The data structure, when 
created, can be thought of as a "household" account, although it does not have to be 
associated with a customer's "household", nor does it preferably contain any actual 
account data. Instead, the "household" account can be arbitrarily defined, and may 
only includes a number of links that identify or point to other accounts within the 
system. 

Several such household accounts are shown at 90a, 90b, and 90c. Household 
account 90a includes links to accounts 92a, 92b and 92c. Likewise, household 
account 90b includes links to accounts 92c and 92e. As indicated above, the links are 
preferably defined by the representative. Once defined and selected, the present 
invention may display the account items that are within the accounts identified by the 
one or more links of the selected household account data structure. The household 
accounts may be saved for later reference and use. 

It is contemplated that the "household" accounts may link, point to, or pull in 
data from other databases, such as databases 30b and 30c (see Figure 2). For 
example, database 30c may include account or other information from a remote 
brokerage house, bank or the like. In this example, the "household" account may 
link, point to, or pull in account information from database 30c. This illustrates that 
the "household" accounts may include references to both local and remote databases, 
if desired. 

To provide a degree of hierarchy, a household account may include a link to 
one or more other household accounts. Such a data structure is shown at 94, and may 
be referred to as a household-of-households account. When a household-of- 
households account is selected, the present invention preferably displays the account 
items within the accounts directly identified by the one or more links of the 
household-of-households account, as well as the account items within the one or 
more accounts identified by the links in the identified sub-household account or 
accounts. For example, when household-of-households account 94 is selected, the 
present invention preferably displays the account items within accounts 92a, 92b, 92c 
which are identified by the links of household account 90a, account items within 
accounts 92c and 92e which are identified by the links of household account 90b, as 
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well as account 92f which is directly identified by a link of household-of-household 
account 94. 

Multiple levels of household-of-household accounts may be created, 
providing maximum flexibility to the representative. An advantage of using a data 
structure that only includes links rather than actual account data is that the displayed 
account items are collected from the actual accounts at the time of display, and are 
therefore up-to-date. For this reason, the household (and household-of-household) 
accounts may be referred to as dynamic link accounts. 

To simplify the display of account items, related account items from the 
various accounts identified by a household account may be combined before the data 
items are displayed. An example account item that may be combined is a stock 
position in a particular company. To do this, the account items that are related are 
first identified. Then, the related account items are combined by, for example, 
summing the stock positions for the particular company, and outputting a single 
collective account item for display. In this example, an average or effective purchase 
price for the stock may be computed and also displayed. By combining related 
account items, the number of account items that are displayed may be reduced. In 
addition, the representative may more clearly see the particular emphasis of the 
customer's portfolio. Various reports may also be run on the individual accounts or 
household (or household-of-household) accounts, as desired. 

Nothing in Kenna et al. appears to suggest, for example, a first data structure that includes two or 

more associated links, wherein each link identifies one or more of the accounts , and display means 

for displaying selected account items from the accounts identified by the two or more links of the 

first data structure , as recited in claim 1 . The Examiner cites to column 9, lines 46-63 of Kenna et al. 

as suggesting the first data structure, which states: 

Portions of the data processing system may reside on the individual 
workstations. Also connected to network server 650 is a link to an insurer 670 for 
real-time data exchange between the financial service institution ("the administrator") 
and the insurer providing the catastrophic insurance coverage. Additional links , such 
as 690, are possible for multiple insurance providers. Data link 660 (and additional 
links such as 680) is provided for communication between the administrator and a 
third party network providing debit card services. Examples of such service providers 
are VISA, Mastercard, American Express, and numerous banking institutions having 
debit cards. This link is the primary data input facility for claim submission to the 
MSA account. A debit card swiped through a point-of-sale terminal at a health 
provider's location initiates a temporary connection through the debit card network to 
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submit a claim to the administrator 's computer 600. 
(Kenna et al., column 9, lines 46-63). The link referred to in the above passage of Kenna et al. 
appears to refer to a data link to provide communication between computer systems. However, such 
a data link is typically not a data structure, and more specifically, is not a data structure that has two 
or more associated links, wherein each link identifies one or more of the accounts, as recited in claim 
1. Further, there does not appear to be any discussion of a display means for displaying selected 
account items from the accounts identified by the two or more links of the first data structure , as 
recited in claim 1 . In view of the foregoing, claim 1 is believed to be clearly patentable over Kenna 
et al. For similar and other reasons, independent claim 16 and dependent claims 2, 4 and 6-15,19, 
20 and 23 are also believed to be clearly patentable over Kenna et al. If the Examiner elects to 
maintain the rejection, Applicants respectfully request that the Examiner specifically point out where 
in Kenna et al. each and every limitation of claim 1 is disclosed. 

On page 5 of the Office Action, the Examiner states that Kenna et al. suggest each and every 
element of claim 36 (citing Kenna et al., column 9, line 33 to column 1 1, line 58). After carefully 
reviewing Kenna et al., Applicants must respectfully disagree. Claim 36 recites: 

36. A method for accomplishing a stock deposit in a financial services 
firm having a ledger, the stock deposit being for a specified number of shares of a 
specified company, the method comprising: 

selecting a customer account having a customer account identifier from a data 
processing system; 

entering the specified number of shares into the data processing system; 

entering an identifier of the specified security into the data processing system; 

entering at least one stock certificate number into the data processing system; 

generating a stock power that can be readily printed using the customer 
account identifier, the specified number of shares, the security identifier and the at 
least one stock certificate number; 
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creating an entry in the customer account designated by the customer account 
number , the entry representing the deposited stock; and 

entering the stock deposit in the blotter of the financial services business. 

First off, the portion of Kenna et al. cited by the Examiner appears to relate to a Medical Savings 

Account (MSA). According to Kenna et al., each subscriber's account includes, in addition to 

transactional data, a series of descriptive parameters. Table- 1 in column 10 of Kenna et al. lists 

several example parameters which may be recorded. Kenna et al. state: 

Basic information, such as subscriber's name, address, dependents and indication 
of whether the account is individual or employer-sponsored, is maintained for all 
accounts. Additional parameters which may be used include an employer or group 
affiliation number to identify a class of account that a subscriber is a member of; 
the deductible, DEDUCT(I), which applies to the associated catastrophic health 
insurance policy; the annual premium, ANN-PREM(I), for this policy; and the 
periodic due dates or number of cycles for premium contributions, PREM- 
DUE(I). Additional parameters record the subscriber's bank and account numbers 
for direct deposit or Funds Transfers Service funding of the MSA; the respective 
percentages of funding by an employer or employee; and the due dates of these 
contributions, PERIOD(I). Further optional parameters, whose use will be 
described later, include such items as a debit card float or loan limit, ACCT- 
LIMIT(I) Calculator, and parameters to allow a subscriber to skip a periodic 
contribution or make an extra payment. Other parameters may be added to the 
database to realize the desired processing control for particular or groups of 
accounts. 

(Kenna et al., column 10, lines 24-45). Notable, none of these parameters appear to relate to 
accomplishing a stock deposit in a financial services firm having a ledger, the stock deposit being for 
a specified number of shares of a specified company . In addition, there does not appear to be any 
suggestion whatsoever in the cited portion of Kenna et al. for performing virtually any of the steps 
of: (1) selecting a customer account having a customer account identifier from a data processing 
system; (2) entering the specified number of shares into the data processing system; (3) entering an 
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identifier of the specified security into the data processing system; (4) entering at least one stock 
certificate number into the data processing system; (5) generating a stock power that can be readily 
printed using the customer account identifier, the specified number of shares, the security identifier 
and the at least one stock certificate number; (6) creating an entry in the customer account designated 
by the customer account number, the entry representing the deposited stock; or (7) entering the stock 
deposit in the blotter of the financial services business, as recited in claim 36. In view of the 
foregoing, claim 36 is believed to be clearly patentable over Kenna et al. Again, if the Examiner 
elects to maintain this rejection, Applicants respectfully request that the Examiner specifically point 
out where in Kenna et al. each and every limitation of claim 36 is disclosed. 

In paragraph 8 of the Office Action, the Examiner rejected claims 3, 5, 17, 18 and 42-47 
under 35 U.S.C. § 103(a) as being unpatentable over Kenna et al. in view of Chen et al. (US 
5,590,197). For the same reasons discussed above with respect to independent claims 1 and 16, as 
well as other reasons, Applicants believe that dependent claims 3, 5, 17 and 18 are also believed to 
be clearly patentable over Kenna et al. in view of Chen et al. 

Turning now to claims 42-47. Notably, the Examiner does not appear to specifically address 

the rejection of claims 42-47. After careful review, however, it is clear that Kenna et al. fails to 

suggest a number of limitations of claim 42 as well as other claims. Claim 42 recites: 

42. A broker dealer assistance system, comprising: 

an account database for storing account information, the account information 

for each account including a number of account holdings, a number of investment 

objectives and a number of documented customer contacts; and 

display means for displaying on a single screen or window, or multiple 

screens or windows simultaneously, selected investment objectives and selected 

documented customer contacts for a selected account. 
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As can be seen, Kenna et al. does not appear to suggest an account database for storing account 
information, wherein the account information for each account includes a number of account 
holdings, a number of investment objectives and a number of documented customer contacts . Kenna 
et al. also does not appear to suggest display means for displaying on a single screen or window , or 
multiple screens or windows simultaneously , selected investment objectives and selected 
documented customer contacts for a selected account , as recited in claim 42. Chen et al. adds little to 
Kenna et al. in this regard. Thus, and for these and other reasons, claims 42-47 are believed to be 
clearly patentable over Kenna et al. in view of Chen et al. If the Examiner elects to maintain this 
rejection, Applicants respectfully request that the Examiner specifically point out where in Kenna et 
al. or Chen et al. each and every limitation of claims 42-47 is disclosed. 

In paragraph 9 of the Office Action, the Examiner rejected claim 34 under 35 U.S.C. § 103(a) 
as being unpatentable over Kenna et al. in view of Pickering (US 5,684,965). The Examiner states 
that Kenna et al. suggest a method of providing formatted output of selected fields of a database 
wherein the database includes a number of database entries each having two or more fields, and each 
field having a field value. The Examiner also states that Kenna et al. suggests identifying the 
database entries that have one or more fields with a field value that matches a selected query or 
expression. Finally, the Examiner states that Kenna et al. suggests outputting a formatted output that 
includes the field value of a selected field of each database entry identified by the identifying step 
(citing Kenna et al., column 10, lines 20+). 

The Examiner acknowledges that Kenna et al. fail to suggest that the formatted output is 
formatted to print on printed labels or personal digital assistant. However, the Examiner states that 
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Pickering suggests the generation of printed matter from a computer host to printer (citing, Pickering, 
column 5, lines 12-23). The Examiner concludes that it would have been obvious to integrate a 
printer to print various formatted printed data, such as a label, from a host computer, as taught by 
Pickering, because an artisan would have recognized the advantage of having a physical copy of 
information in order to transport, make corrections to, mail, identify certain material, or any other of 
the various uses that parchment may be used for. The Examiner states that to employ a printer to the 
Kenna system would have been obvious to one or ordinary skill in the art. 

After careful review, Applicants again must respectfully disagree. Claim 34 recites: 

34. A method for providing a formatted output of selected fields of a 
database, wherein the database includes a number of database entries each having 
two or more fields, and each field having a field value, the method comprising: 

identifying the database entries that have one or more fields with a field value 
that matches a selected query or expression; and 

outputting a formatted output that includes the field value of a selected field 
of each database entry identified by the identifying step, wherein the formatted output 
is formatted to print onto printed labels, and wherein each of the printed labels is one 
of an array of printed labels on a sheet of printed labels . 

As can be seen, claim 34 recites outputting a formatted output that includes the field value of a 

selected field of each database entry identified by the identifying step, wherein the formatted output 

is formatted to print onto printed labels . This is illustrated in, for example, Figures 11-12 of the 

present specification. With respect to Figures 1 1-12, the present specification states: 

The illustrative window shown in Figure 1 1 includes four basic sections. The 
first section, called the account registration section 150, allows a representative to 
select a particular representative, the account type desired, the report frequency, and 
the state of residence of the customer. The second section, called the investment 
objective section 152, allows a representative to select customers by various 
investment objectives. The next section, called a personal interest section 154, 
allows a representative to select customers that have a particular hobby or interest. 
Finally, the last section, called the holdings section 156, allows the representative to 
select customers by the type of holdings that they currently own. 
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Once the various menu options are selected, the create mail merge button 158 
may be selected. In the illustrative embodiment, the create mail merge button 158 
causes the system to assembly a query and search the database 30a to identify those 
customers that match the query. The system preferably provides an output that 
includes, for example, the identified customers' names and addresses. The output is 
preferably formatted as a merge document that can be read by an application program 
that has a merge capability (e.g. Microsoft Word®). The merge capability can be 
used to insert the outputted fields into another document such as a letter or a 
promotional item, which can then be easily sent to the identified customers. The 
formatted output can also be formatted for a spreadsheet program, or to print on 
printed labels or envelopes, as desired. Other formats are also contemplated 
including, for example, formats that are compatible with e-mail systems or personal 
digital assistants (PDAs). The mail merge function allows the representatives to 
provide increased customer service with little extra effort. 

Figure 12 is a screen shot showing an illustrative output when the "Create 
Mail Merge" button 158 of Figure 11 is selected. In the illustrative embodiment 
shown, the output is formatted to print on printed labels. The names and addresses of 
the customers identified by the query of Figure 1 1 are formatted so that each 
name/address prints on a separate label of a conventional label sheet. It is 
contemplated that the page shown can be printed directly from within the browser 
program shown, and/or a file can be provided to the representative's local computer 
system, which can then be printed on a local printer. 

(Emphasis Added)(Specification, page 1 8, line 25 through page 1 9, line 24). Nothing in Pickering or 
Kenna et al. appears to suggest formatting and printing onto printed labels. Instead, and as shown in 
Figure 4, Pickering appear to suggest printing a consolidated statement, which is ultimately sent to 
each customer. The statement identifies each of the companies and utilities, as well as which 
companies rendered charges, the charges for the particular billing cycle, and the total amount due for 
paymerit by the customer (77). The statement also includes a remittance stub (79) which is 
selectively detachable from the remainder of the statement along a perforated fold. The remittance 
stub is returned with the customer's payment to the financial firm (see Pickering, column 4, lines 42- 
53). From this, it is clear that Pickering do not suggest outputting a formatted output that is 
formatted to print onto printed labels, as recited in claim 34. Instead, Pickering appear to print out a 
conventional type billing statement that is forwarded to it's customers for payment, and that the 
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billing statement includes a remittance stub which can be selectively detached via a perforated fold. 

Despite the foregoing, and to further clarify the claim, claim 34 has been amended to recite: 

outputting a formatted output that includes the field value of a selected field 
of each database entry identified by the identifying step, wherein the formatted output 
is formatted to print onto printed labels, and wherein each of the printed labels is one 
of an array of printed labels on a sheet of printed labels . 

Clearly, nothing in Pickering or Kenna et al. suggest outputting a formatted output that is formatted 
to print onto printed labels, wherein each of the printed labels is one of an array of printed labels on a 
sheet of printed labels, as now claimed. As such, claim 34 is believed to be clearly patentable over 
Kenna et al. in view of Pickering. Newly presented claims 48-49 have been added as dependent 
claims from independent claim 34. 

In paragraph 10 of the Office Action, the Examiner rejected claim 35 under 35 U.S.C. § 
103(a) as being unpatentable over Kenna et al. in view of Weiser (US 5,982,520). The Examiner 
states that Kenna et al. suggest a method of providing formatted output of selected fields of a 
database wherein the database includes a number of database entries each having two or more fields, 
and each field having a field value. The Examiner also states that Kenna et al. suggests identifying 
the database entries that have one or more fields with a field value that matches a selected query or 
expression. Finally, the Examiner states that Kenna et al. suggests outputting a formatted output that 
includes the field value of a selected field of each database entry identified by the identifying step 
(citing Kenna et al., column 10, lines 20+). The Examiner acknowledges that Kenna et al. fail to 
suggest that the formatted output is formatted to be read into a personal digital assistant. However, 
the Examiner states that Weiser suggests a personal storage device for receipt and transfer of digital 
information to other electronic devices like a personal digital assistant or computer (citing Weiser, 
column 2, lines 3+). 

After careful review, Applicants must respectfully disagree. Claim 35 recites: 

3 5 . (Amended) A method for providing a formatted output of selected 
fields of a database, wherein the database includes a number of database entries each 
having two or more fields, and each field having a field value, the method 
comprising: 
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identifying the database entries that have one or more fields with a field value 
that matches a selected value or expression; and 

outputting a formatted output that includes the field value of a selected field 
of each database entry identified by the identifying step, wherein the formatted output 
is formatted to [print] be read into a personal digital assistant. 

As can be seen, claim 35 recites two steps including: (1) identifying the database entries that have 
one or more fields with a field value that matches a selected value or expression; and (2) outputting a 
formatted output that includes the field value of a selected field of each database entry identified by 
the identifying step, wherein the formatted output is formatted to be read into a personal digital 
assistant. It is the combination of these two steps that is the invention recited in claim 35. 

It does not appear that Kenna et al. suggest the steps of: (1) identifying the database entries 
that have one or more fields with a field value that matches a selected value or expression; or (2) 
outputting a formatted output that includes the field value of a selected field of each database entry 
identified by the identifying step. In support of the rejection, the Examiner cites to column 10, lines 
20+ of Kenna et al. However, the passage at column 10, lines 20-62 appears to merely relate to a 
number of parameters that may be stored for each account. There does not appear to be any 
suggestion of an identifying step, at least an identifying step that identifies database entries that have 
one or more fields with a field value that matches a selected value or expression. Figures 8A-8B, 
which are discussed beginning at the bottom of column 10 of Kenna et al., are a logic flow diagram 
for creating and updating individual accounts, that is, creating and updating the parameters discussed 
in column 10, lines 20-62 discussed above. Notably, there does not appear to be any discussion of 
the identifying or outputting step, as recited in claim 35 (or claim 34 for that matter). 
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Figure 9 A of Kenna et al, which is discussed beginning at the last paragraph of column 11, 
describes a periodic account maintenance routine. According to Kenna et al., the periodic account 
maintenance routine may be run daily, monthly, or at any other appropriate interval, but it must be 
run periodically on each account. Again, the periodic account maintenance routine does not appear 
to include an identifying step, at least an identifying step that identifies database entries that have one 
or more fields with a field value that matches a selected value or expression. Also, there does not 
appear to be any discussion of outputting a formatted output that includes a field value of a selected 
field of each database entry identified by the identifying step. 

While Weiser et al. appear to suggest a personal storage device for receipt and transfer of 
digital information generally to other electronic devices, Weiser et al. do not appear to suggest either 
the identifying or outputting steps of claim 35. As such, the combination of Kenna et al. and Weiser 
et al. cannot render claim 35 obvious. In view of the foregoing, claim 35 is believed to be clearly 
patentable over Kenna et al. and Weiser et al. 

In paragraph 1 1 of the Office Action, the Examiner rejected claims 37-41 under 35 U.S.C. § 
103(a) as being unpatentable over Shurling et al. (US 6,009,415). The Examiner states that Shurling 
et al. suggest a method of determining the productivity of customer referrals from a number of 
customer referral sources (customer data 32). The Examiner states that Shurling et al. suggest the 
steps of: storing a customer referral source identifier (Customer Information file ("CIF) - 30) for 
each referred customer (citing Shurling et al., column 4, lines 10-24); and determining a total number 
of customer referrals for each customer referral source (citing Shurling et al., column 4, lines 27-32). 

The Examiner acknowledges that Shurling et al. fail to suggest providing a visual comparison 
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of the total number of customer referrals for a selected referral source against the average of the total 
number of customer referrals for all customer referral sources. However, the Examiner states that 
since Shurling et al. suggest relationship scoring (or customer referral scoring), it would have been 
obvious for an artisan of ordinary skill in the art to consider the standard deviation of a particular 
score with the average score of the total number of customer referrals to provide better incentives for 
customers to use their services. The Examiner concludes, it would have been an obvious matter of 
design choice well within the ordinary skill of the art to modify Shurling et al. to employ a 
comparison. 

After careful review, Applicants must respectfully disagree. Claim 37 recites: 

37. A method for determining the productivity of customer referrals from 
a number of customer referral sources, the method comprising the steps of: 

storing a customer referral source identifier for each referred customer; 
determining a total number of customer referrals for each customer referral 

source; 

determining an average of the total numbers of customer referrals for all 
customer referral sources; and 

providing at least a visual comparison of the total number of customer 
referrals for a selected customer referral source against the average of the total 
numbers of customer referrals for all customer referral sources. 



It is well known that to establish prima facie obviousness of a claimed invention, all the claim 
limitations must be taught or suggested by the prior art. In re Royka, 490 F.2d 981, 180 USPQ 580 
(CCPA 1974). "All words in a claim must be considered in judging the patentability of that claim 
against the prior art.' V/i re Wilson, 424 F.2d 1382, 1385, 165 USPQ 494, 496 (CCPA 1970). In the 
present case, Shurling et al. do not suggest, for example, the steps of determining an average of the 
total number of customer referrals for all customer referral sources, or providing at least a visual 
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comparison of the total number of customer referrals for a selected customer referral source against 
the average of the total numbers of customer referrals for all customer referral sources. The 
Examiner appears to acknowledge this in his remarks. Therefore, the Examiner has clearly failed to 
show that each of the limitations of claim 37 were taught or suggested by the prior art, and therefore 
according to In re Royka, has failed to establish a prima facie case of obviousness. 

If anything, Shurling et al. suggests providing a score for selected bank customers, wherein 
the score includes a number of factors including possibly a factor related to the number of customer 
referrals. However, Shurling et al. does not appear to ever isolate the factor related to customer 
referrals. Rather it always appears to be rolled into a general customer score. In addition, Shurling 
et al. never appear to determine or compare the productivity of certain customer referrals. This was 
just not contemplated by Shurling et al. These differences are substantial. As noted in the present 
specification: 

For many representatives, customer referrals are a primary source of business. 
As such, tracking the productivity of customer referrals is a tool that can be used to 
increase a representative's business. In the illustrative embodiment, the productivity 
of customer referrals is computed by storing a customer referral source identifier for 
each referred customer. For example, Joseph Client was referred to the 
representative by Scott O. Fergusson, as shown at 3 14A. A total number of customer 
referrals for each customer referral source is then computed, along with an average 
number of customer referrals across all customer referral sources. Referring 
specifically to the referral productivity section 308 of Figure 28, the total number of 
customer referrals referred to the representative by Joseph Customer is seven (7), and 
the average number of customer referrals across all customer referral sources is three 
(3), as generally shown at 3 1 0. This information is shown both as a bar graph as well 
as printed data. 

Because some customer referrals generate more commission than others, the 
present invention also contemplates measuring the productivity of customer referrals 
by commissions received instead of just mere number of referrals. In this illustrative 
embodiment, a total dollar amount of commissions received by the representative 
from customers referred from each customer referral source is computed. Then, an 
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average dollar amount is computed for all customer referral sources. Referring again 
to the referral productivity section 308 of Figure 28, the total dollar amount of 
commissions received by the representative from Joseph Customer is $2,439, and the 
average dollar amount of commissions received by the representative across all 
customer referral sources is $204, as generally shown at 312. This information is 
again shown both as a bar graph as well as printed data. As can be seen, Joseph 
Customer has a much higher referral productivity than the average customer of the 
representative. This information may indicate to the representative that Joseph 
Customer is a particularly important customer. 

To help identify productive customers, a measure of the relative productivity 
of any given customer referral source can be determined by comparing the total dollar 
amount of commissions for a selected customer referral source against the average 
dollar amount received across all customer referral sources. Alternatively, or in 
addition, those customer referral sources that are, for example, in the top "n" percent 
of productivity may be identified and displayed. If desired, the system may output a 
merge output that includes the particularly productive customer referral sources. The 
representative may use the merge output to generate, for example, a thank your letter 
or an invitation to a special event for those customers. 

(Specification, page 25, line 31 through page 27, line 4). In view of the foregoing, to state that 

Applicant's invention is simply a matter of design choice, without providing a single reference that 

shows the last two steps of claim 37, is believed to be unfair and improper. It appears the Examiner 

is using the claimed invention as an instruction manual or "template" to piece together the teachings 

of the prior art so that the claimed invention is rendered obvious. The court has frequently warned, 

however, that "'[o]ne cannot use hindsight reconstruction to pick and choose among isolated 

disclosures in the prior art to deprecate the claimed invention. 5 (quoting In re Fine, 837 F.2d 1071, 

1075,5USPQ 2d 1596, 1600 (Fed. Cir. 1988)."//i reFr/*cA,23USPQ2d 1780, 1783-84 (Fed. Cir. 

1992). In view of the foregoing, claim 37 is believed to be clearly patentable over Shurling et al. 

For similar and other reasons, claims 3 8-4 1 are also believed to be clearly patentable over Shurling et 

al. 
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Finally, Applicants note that claims 21 and 23-33 were not specifically rejected under 35 
U.S.C. § 102 or § 103, and thus are believed to be in condition for allowance. 

In view of the foregoing, all pending claims 1-49 are believed to be in condition for 
allowance. Reexamination and reconsideration are respectfully requested. If the Examiner would 
like to discuss the application or its examination in anyway, please call the undersigned attorney at 
(612) 677-9050. 



Respectfully submitted, 



Scott Fergusson 




1221 Nicollet Avefaue, Suite 800 
Minneapolis, MN 55403-2402 
Telephone: (612)677-9050 
Facsimile: (612)359-9349 



& TUFTE, LLC 



20 



Serial No. 09/917,120 

Version With Markings to Show Changes Made 

Claims 1, 16, 24-26 and 34-35 have been amended as follows: 

1. (Amended) A system for displaying account information from two or more 
accounts that are stored in one or more account database, wherein each account includes one or more 
account items, the system comprising: 

a first data structure having [one] two or more associated links, wherein each link identifies 
one or more of the accounts; and 

display means for displaying selected account items from the accounts identified by the [one] 
two or more links of the first data structure. 



16. (Amended) A method for displaying account information from two or more 
accounts that are stored in one or more account database, wherein each account includes one or more 
account items, the method comprising: 

providing a first data structure having [one] two or more associated links, wherein each link 
identifies one or more of the accounts; and 

displaying selected account items from the accounts identified by the [one] two or more links 
of the first data structure. 

24. (Amended) A method for providing a formatted output of selected fields of a 
database for a computer program with a merge capability , wherein the database includes a number of 
database entries each having two or more fields, and each field having a field value, the method 
comprising: 

identifying the database entries that have one or more fields with a field value that matches a 
selected query or expression; and 

outputting a formatted output that includes the field value of a selected field of each database 
entry identified by the identifying step, wherein the formatted output is formatted as a merge 
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document that can be read by the computer program with the merge capability [another program with 
a merge capability]. 

25. (Amended) A method according to claim 24 wherein the computer program is a 
word processing program. 

26. (Amended) A method according to claim 24 wherein the computer program is a 
publishing program. 

34. (Amended) A method for providing a formatted output of selected fields of a 
database, wherein the database includes a number of database entries each having two or more fields, 
and each field having a field value, the method comprising: 

identifying the database entries that have one or more fields with a field value that matches a 
selected query or expression; and 

outputting a formatted output that includes the field value of a selected field of each database 
entry identified by the identifying step, wherein the formatted output is formatted to print onto 
printed labels , and wherein each of the printed labels is one of an array of printed labels on a sheet of 
printed labels . 

35. (Amended) A method for providing a formatted output of selected fields of a 
database, wherein the database includes a number of database entries each having two or more fields, 
and each field having a field value, the method comprising: 

identifying the database entries that have one or more fields with a field value that matches a 
selected value or expression; and 

outputting a formatted output that includes the field value of a selected field of each database 
entry identified by the identifying step, wherein the formatted output is formatted to [print] be read 
into a personal digital assistant. 
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